-
Notifications
You must be signed in to change notification settings - Fork 969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[naga/spv-in] Remove unnecessary "gl_PerVertex" name check so unused builtins will always be skipped #5227
Conversation
0d40f54
to
10b3e98
Compare
This looks good, could we also take out the block below? I don't think we should be naming things if they don't have a name in the input. wgpu/naga/src/front/spv/mod.rs Lines 5130 to 5139 in 665c075
|
That would be great, thanks!
Yes.
SPIR-V does support multiple entry points per file but they are not common.
This is a good point, we might need to defer the removal. |
This seems to be the case, I was able to get spv-in to remove the builtin from position by moving positing setting out of the main function: #version 450
out gl_PerVertex {
vec4 gl_Position;
float gl_ClipDistance[1];
};
void builtin_usage() {
gl_ClipDistance[0] = 1.0;
gl_Position = vec4(
(gl_VertexIndex == 0) ? -4.0 : 1.0,
(gl_VertexIndex == 2) ? 4.0 : -1.0,
0.0,
1.0
);
}
void main()
{
builtin_usage();
} glslc test.vert -o test.spv
cargo r --bin naga test.spv
|
I'm reading the code further and I realized that this section of code only runs for the entry point function, so the issue is not quite as bad as I make it seem here. It seems like it's only an issue if the entry point itself doesn't access the builtin while another function that the entry point calls does access it. |
since we probably shouldn't be naming things if they don't have a name in the input. As requested here: gfx-rs#5227 (comment)
10b3e98
to
652b9ba
Compare
since we probably shouldn't be naming things if they don't have a name in the input. As requested here: gfx-rs#5227 (comment)
652b9ba
to
bf54971
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notes for additional context
Added input spv to test for the original issue as well as another to test for the case of builtin's being accessed in a function parsed after the entry point.
I ended up finding a way to defer this by postponing the entry point related processing to be after all function parsing. If this change is too much for this PR I can move it into a separate one.
Removed this block. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff, thanks!
One last thing, I would like to "rebase and merge" this PR instead of squashing it. Could you include the changes in the last commit ("fix typo") in the appropriate commits that introduced those? |
handled even when this name is not in the input SPIRV.
since we probably shouldn't be naming things if they don't have a name in the input. As requested here: gfx-rs#5227 (comment)
…are found before culling the unused ones
…entry point function
4e34662
to
bef7ac9
Compare
done |
since we probably shouldn't be naming things if they don't have a name in the input. As requested here: #5227 (comment)
Connections
Fixes #4915
Description
Unused gl_PerVertex builtins need to be skipped since they my otherwise require capabilities that are not enabled. However, this was not being done when the input spirv didn't explicitly name this struct.
This just removes the check against the "gl_PerVertex" name as suggested in #4915 (comment). Assuming valid SPIRV, this is technically equivalent to #4915 (comment) because a struct with builtin members must be decorated as a
Block
Would it be worth adding a test for this? If so, would that go under
naga/tests/in/spv
?Also, I'm not very familiar with the overall structure of SPIRV nor with the spv frontend for naga. Can parse_function run more than once for a particular input? If so, is it possible that later functions will be using the builtin but we remove the builtin label after not seeing any uses when processing the first function?
Testing
I produced a .spv file using the method described in #4915 and confirmed that this change removes the error there. I also tested an application using
shaderc
to generate SPIRV forwgpu
that was seeing this error with certain configurations ofshaderc
and confirmed that the issue was resolved (and that everything seemed to work).Checklist
Run
cargo fmt
.Run
cargo clippy
. If applicable, add:--target wasm32-unknown-unknown
--target wasm32-unknown-emscripten
Run
cargo xtask test
to run tests.Some failures but they also fail on `trunk`
Add change to
CHANGELOG.md
. See simple instructions inside file.Edit:
Additional changes
parse_function
was extracted and now runs after all functions are parsed. Since this includes the code that does gl_PerVertex builtin culling, we can be sure that any potential access has been registered.